當前置內容都有一個明確討論了，接著要開始行動了，行動的時候就不會只有自己一個人了，是有可能小則4人組織、大則上百人的規模，所以變成執行內容和項目，要盡可能的明確清楚，讓所有的人員可以了解自己所要執行細節。

軟體沒有做不到，只有想不到，但執行策略要訂好，不要做什麼都要有的服務

當執行者有發現問題時，就要需要馬上思考，選擇那一種方案執行是相對好的；做了PM後，可以更能分辨出各種function 解決方法的優劣，沒有絕對好或不好，而是適不適合當下這情境。

舉例來說，一個產品規格書PRD，章節內容都會很多，如果是用常見的直式目錄羅列章節，可能導致閱讀者需要一直上下滾動滑鼠才可以看到全貌章節，但如果是做成橫向章節列表，往往在一個視窗上就可以看完全貌，但這必須人工進行編輯；方案沒有好壞，只有合不合適當下需求，以及可解決問題的範圍多大，對於使用者、執行者及開發時程之間取得一個較佳的平衡

再舉例來說，APPLE串流服務中，看起來都是影片，但他們的決策行動，是依據是否為自製內容，作為切分，APPLE 的自製內容只能在APPLE TV+看得到，如果要看非APPLE自製內容，只能在商店租任和購買

(圖片取至APPLE TV)

所以決策的行動，都會在取得一個平衡點後，往下進行的內容，而進行的方式和規則，就需要盡可能完整的描述交付給執行團隊進行。

設計交付

交付是一件很重要的行動，是讓團隊的所有人，可以有一個依據往前走，所以交付的內容要一致，避免前後衝突或是資訊遺漏。

就如2024巴黎奧運CIS文件就寫得很明確，讓執行者可以直接取用(Web)，一個CIS系統就寫了136頁，滿滿的說明及示範，就連路人甲都可以照做出來了。

因此，當要開使執行決策內容，盡可能站在執行者的角度來看，這樣在描述內容時，才比較不會忽略細則；但其實，再怎麼想像也還是有可能會遺漏，這時也不要灰心，就是要疏漏的內容再補上，在通知執行端，然後做好更新紀錄內容，即能可持續進行。

可參考下列原則

內容明白：寫明白，寫清楚保持彼此獨立，互無遺漏的原則(MCME)進行撰寫。

圖文對照：如果複雜或行為面的內容，盡可能用圖片及文字交互的說明，這樣可以協助閱讀者可以更快理解內容。

目錄查詢：有一個完整目錄，讓不同成員可以直接按目錄進行檢索，可以直接找到他們當下所需要的資料，可以執行進行他們的任務

持續更新：每當開發持續地推進，所發現的問題和未能及時想到的內容，也會慢慢浮出來，需要能即時的處理、決議，然後加入到交付內容中，以能維持完整性

更新通知：當有任何變更、新增或調整，都盡可能通知到鄉端執行人員，避免資訊落差，減少團隊合作上的摩擦。

Take away

執行內容僅可能完整撰寫描述，採以執行者的角度思考如何讓他們可以輕鬆開始任務的角度轉寫，以利於減少溝通成本

但如非能一開始，就將內容都明確寫進去，也不用灰心，僅需要將內容即時更新，通知到執行人員，讓執行人員可以理解進行。

決策通常這件事，不太可以今天決定了，就會一直走到事情做完，很常的狀況是今天講可能下週就不一樣了，這才是真正的常態，所以就ㄧ定要考量到新增補充變更內容的彈性。